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INFORMATION RELAY DEVICE AND METHOD WITH MULTICAST 
PROTOCOL /conversion FUNCTION AND INFORMATION NETWORK 

SYSTEM USING THE SAME 

BACKGROUND OF THE INVENTION 

The present invention relates to an information 
relay device and method in which an operation for relay 
of information between a plurality of logical or physical 
5 information networks is performed and an information 
network system which uses such a device or method, and 
more particularly to an information relay device such as 
a bridge, router or LAN switch provided with a multicast 
protocol conversion function in which an operation for 

10 relay of multicast infojrmation between infoirmation 

networks is performed, an information relay method which 
is used in such a device and an information network 
system which uses such a device or method. 

For example, in the field of information 

15 communication, a method called multicast communication 
(or transmission) is generally known as a method for 
performing the simultaneous delivery (or transmission) of 
the same data from one host to a plurality of hosts. In 
the multicast communication, one group is formed by a 

20 plurality of hosts and the same data is delivered to all 
hosts in this group by use of one multicast packet. 
Also, in TCP/IP (Transmission Control Protocol/Internet 
Protocol) as a standard protocol in the Internet, there 
is a technique called IP multicast in which the above 
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multicast communication is used. 

In the IP multicast, a specified IP address 
called IP multicast address is defined for each group and 
data is delivered to each host by use of an IP multicast 
5 packet with the IP multicast address taken as a receiver 
(or destination) IP address. 

As one protocol for IP multicast, there is IGMP 
{Internet Group Management Protocol) described in RFC 
(Request For Comment) 1112, 2236 and draft (whose last 

10 edition on Februairy 1999 is draf t-ietf -idmr-igmp-v3- 
Ol.txt). The IGMP is a protocol for a request for 
multicast communication which is made from a host to an 
adjacent router. With the IGMP, the host is enabled to 
receive an IP multicast packet. 

15 The IGMP is a protocol in the third layer (or 

network layer) of an OSI (Open Systems Interconnect) 
reference model. 

On the other hand, GMRP (GARP (Generic 
Attribute Registration Protocol) Multicast Registration 

20 Protocol) described in IEEE (Institute of Electrical and 
Electronics Engineers) 802. Id draft (whose last edition 
on June 1998 is IEEE802 . ld/D17 ) exists as one protocol 
for multicast communication in the second layer (or data 
link layer) of the OSI reference model. 

25 The GMRP is a protocol for a request for 

multicast communication in the data link layer which is 
made from a host to an adjacent bridge or LAN (Local Area 
Network) switch. With the GMRP, the host is enabled to 
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receive a multicast packet in the data link layer. 
Hereinafter, this multicast packet in the data link layer 
will be referred to as MAC (Media Access Control) 
multicast packet, A difference between the IGMP and the 
5 GMRP lies in that the IGMP is a protocol specified for IP 
whereas the GMRP is a protocol independent of the network 
layer . 

SUMMARY OF THE INVENTION 

The former protocol IGMP mentioned above is 

10 standard-wise mounted on, for example, WINDOWS 95 or the 
like which has come into wide use as an OS for a personal 
computer or the like. Therefore, the IGMP has a merit 
that it can easily be utilized. However, since the 
multicast is performed with an IP address, as mentioned 

15 above, it is not possible to perform, for example, 

delivery or transmission with a construction in an IP 
subnet taken into consideration. Namely, a multicast 
packet from a multicast server is equally relayed to not 
only a host in an IP subnet making a declaration of 

20 joining to multicast but also all switches and hosts in 
the IP subnet to which the declaring host belongs* 
Accordingly, there is a technical problem that an 
unavailing traffic in the IP subnet increases due to the 
multicast . 

25 A demand for control/reduction of a traffic 

caused from the multicast blecomes greater when the wide 
use of so-called push type information delivery services 
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using a multicast function in the Internet or the like is 
taken into consideration. 

In the latter protocol GMRP, on the other hand^ 
the multicast is performed with a MAC address. There- 
5 fore, a relay device can selectively relay a multicast 
packet to only a host making a declaration of joining to 
the multicast (or a port to which the declaring host is 
connected) , thereby making it possible to avoid the 
generation of an unavailing traffic. However, a pre- 

10 requisite is that the GMRP's are mounted on all relay 

devices or hosts connected to the network. Accordingly, 
there is a technical problem that easy/convenient wide 
use or utilization is difficult. Namely, since the 
number of hosts such as existing personal computers 

15 connected to information networks with the wide use of 

the Internet or the like is very large, it is practically 
difficult to expect the mounting of GMRP's on all these 
hosts . 

An object of the present invention is to 
20 provide an information relay device and an information 
relay method which makes it possible to realize a 
multicast service without increasing the traffic of a 
network beyond the requisite cimount thereof, and an 
information network system which uses such a device or 
25 method. 

Another object of the present invention is to 
provide an information relay device and an information 
relay method which makes it possible to realize the 
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simplification of mounting of multicast software in a 
host connected to a network and utilizing a multicast 
service, and an information network system which uses 
such a device or method. 
5 A further object of the present invention is to 

provide an information relay device and an information 
relay method which compatibly enables the suppression of 
a traffic increase of a network caused from a multicast 
seirvice and the easy/convenient realization and utiliza- 

10 tion of the multicast service, and an infoirmation network 
system which uses such a device or method. 

A still further object of the present invention 
is to provide an information relay device and an informa- 
tion relay method which compatibly enables the simplifi- 

15 cation of mounting of multicast software in a host 

connected to a network and the utilization of a variety 
of multicast protocols, and an infommation network system 
which uses such a device or method. 

To that end, in the present invention, an 

20 information relay device for performing an operation for 
relay of information between a plurality of logical or 
physical networks is provided with a multicast protocol 
conversion unit for making conversion between different 
multicast protocols which function in different level 

25 layers of a general purpose multicast message protocol, 
for example, different layer levels of an OSI reference 
model . 

According to one aspect of the present 



- 6 . 

invention, an information relay device connected between 
a plurality of logical or physical networks for perform- 
ing an operation for relay of information between the 
networks includes a transmit/receive processing unit for 
receiving a general purpose multicast message from one of 
the plurality of networks and transmitting a multicast 
message to at least one of the plurality of networks, and 
a protocol conversion processing unit for converting, in 
the case where the general purpose multicast message 
received by the transmit/receive proces jsinq unit is a 
multicast protocol message of a certain levejT^ayer, the 
multicast protocol message o^ the*"*c^t^i'h level layer 
into a multicast protocol message of another level layer. 

With the information relay device of the 
present invention having such a construction, there is 
obtained an effect that a multicast service can be 
realized without increasing the traffic of a network 
beyond the requisite amount thereof. 

Also, there is obtained an effect that the 
simplification of mounting of multicast software in a 
host connected to a network and utilizing a multicast 
service can be realized. 

Also, there is obtained an effect that the 
suppression of an increase in traffic in a network caused 
from a multicast service and the easy/convenient realiza- 
tion and utilization of the multicast service are 
compatibly enabled. 

Also, there is obtained an effect that the 
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simplification of mounting of multicast software in a 
host connected to a network and the utilization of a 
variety of multicast protocols are compatibly enabled. 

According to an example of the present inven- 
5 tion, when a multicast protocol (IGMP, DVMRP, MOSPF, 
PIM-SM, PIM-DM, CBT, MLD or the like) message in the 
third layer (or network layer) of an OSI reference model 
is received, the protocol conversion processing unit 
converts this message into a multicast protocol (GMRP or 

10 the like) message in the second layer (or data link 
layer) and transmits the converted message. 

According to another example of the present 
invention, when a multicast protocol (GMRP or the like) 
message in the second layer (or data link layer) is 

15 received, the protocol conversion processing unit 

converts this message into a multicast protocol (IGMP, 
DVMRP, MOSPF, PIM-SM, PIM-DM, CBT, MLD or the like) 
message in the third layer (or network layer) and 
transmits the converted message. 

20 According to a further example of the present 

invention, there is provided with a function of perform- 
ing the conversion from a multicast protocol in the 
second layer (or data link layer) into a multicast 
protocol in the third layer (or network layer) for all 

25 possible combinations of protocols. 

According to a still further example of the 
present invention, a conversion table is provided, as 
required, so that the conversion from a multicast 
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protocol in the second layer (or data link layer) into a 
multicast protocol in the third layer (or network layer) 
is made using a prefix portion of a multicast address 
registered in the conversion table beforehand, 
5 According to a furthermore example of the 

present invention, a unit for monitoring a multicast 
packet flowing in a network and a conversion table are 
provided so that a prefix portion of a multicast address 
of the monitored multicast packet is registered into the 
10 conversion table and the conversion from a multicast 

protocol in the second layer (or data link layer) into a 
/multicast protocol ^^^^^--the^third.^ayer (or network layer) 
is made using the prefix portion ^f the multicast address 



registered in the conversion table. 

15 BRIEF DESCRIPTION OF THE DRAWINGS 

Figs . lA and IB are block diagrams showing an 
example of the construction of an information network 
system including an inter-LAN relay device according to 
an embodiment of an information relay device of the 
20 present invention; 

Fig. 2 is a flow chart showing an example of a 
multicast receive processing accompanied with a proces- 
sing for conversion from L3 multicast protocol into L2 
multicast protocol in the information relay device of the 
25 present invention; 

Fig. 3 is a flow chart showing an example of a 
forwarding processing in L2 multicast in the information 



relay device of the present invention; 

Fig. 4 is a flow chart showing an example of a 
general processing for conversion from L3 multicast 
protocol into L2 multicast protocol in the information 
5 relay device of the present invention; 

Fig. 5 is a diagram showing an example of an Ij2 
multicast table in the information relay device of the 
present invention ; 

Fig. 6 shows an example of a message format of 
10 IGMP which is an example of a multicast protocol of L3 
level ; 

Fig. 7 is a diagram showing examples of the 
type of an IGMP message; 

Fig. 8 shows an example of a message format of 
15 GMRP which is an example of a multicast protocol of L2 
level; 

Fig. 9 is a diagram showing examples of the 
type of a GMRP message; 

Figs. lOA and lOB show an example of a method 
20 for conversion between IPv4 multicast address and L2 

multicast address in the information relay device of the 
present invention ; 

Fig. 11 is a flow chart showing an example of 
an L2 multicast protocol processing in the information 
25 relay device of the present invention in the case where 
an L2 multicast protocol is GMRP; 

Fig. 12 is a flow chart showing an example of a 
processing for conversion into L2 multicast protocol in 
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the information relay device of the present invention in 
the case where an L3 multicast protocol is IGMP; 

Fig. 13 is a flow chart showing an example of a 
receive processing in a general processing for conversion 
5 from L2 multicast protocol into L3 multicast protocol in 
the information relay device of the present invention; 

Fig. 14 is a flow chart showing an example of 
the general processing for conversion from L2 multicast 
protocol into L3 multicast protocol in the information 
10 relay device of the present invention; 

Fig. 15 is a flow chart showing an example of a 
conversion processing in the information relay device of 
the present invention in the case where an L2 multicast 
protocol is GMRP and an L3 multicast protocol is IGMP; 
15 Figs. 16A and 16B show an example of a method 

for conversion between IPv6 multicast address and Ij2 
multicast address in the information relay device of the 
present invention; 

Fig. 17 is a block diagram showing the 
20 construction of a modified example of the information 
relay device of the present invention; 

Fig. 18 is a diagram showing an example of a 
conversion table, in the information relay device of the 
present invention, in which prefix addresses collected 
25 from multicast protocol packets are stored; 

Fig. 19 is a flow chart showing an example of a 
processing for monitoring of a multicast packet in the 
modified example of the information relay device of the 
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present invention; 

Fig. 20 shows an example of a relationship in 
conversion between L2 multicast protocol and L3 multicast 
protocol in the information relay device of the present 
5 invention; 

Fig. 21 is a diagram showing an example of the 
flow of information with a conversion between multicast 
protocols in the information relay device of the present 
invention; 

10 Fig. 22 shows an example of a message format of 

DVMRP which is an example of an L3 multicast protocol; 

Fig. 23 shows an example of a message format of 
PIM-DM/PIM-SM which is an example of the L3 multicast 
protocol ; 

15 Fig. 24 shows an example of a message format of 

CBT which is an example of the L3 multicast protocol; 

Fig. 25 shows an example of a message format of 
MOSPF which is an example of the Ij3 multicast protocol; 

Fig. 26 shows an example of a message format of 
20 MLD which is an example of the L3 multicast protocol; 

Fig. 27 shows an L3 multicast table in the 
information relay device of the present invention; 

Fig. 28 is a flow chart showing an example of a 
processing for relay of a multicast packet in the 
25 information relay device of the present invention; 

Figs. 29A and 29B are diagrams showing an 
example of the operation and effect in the case where 
each of all information relay devices installed in 
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information networks is provided with a function of 
conversion between L2 and L3 multicast protocols 
according to the present invention; and 

Figs. 30A and 30B are diagrams showing an 
5 example of the operation and effect in the case where 

only an information relay device on the backbone side in 
infoirmation networks is provided with the function of 
conversion between L2 and L3 multicast protocols 
according to the present invention. 



10 DESCRIPTION OF THE EMBODIMENTS 

Embodiments of an information relay device and 
method according to the present invention and an 
information network system using the same will now be 
described in reference to the accompanying drawings . 

15 Fig. lA is a block diagram showing an example 

of the construction of an information network system 
including an inter-LAN relay device which is an 
embodiment of an information relay device according to 
the present invention. 

20 In the following description, a conversion 

between a multicast protocol in the second layer (or data 
link layer) of an OSI reference model and a multicast 
protocol in the third layer (or network layer) thereof 
will be described as an example of a conversion proces- 

25 sing performed by the inter-LAN relay device. In the 

following, the second layer (or data link layer) and the 
third layer (or network layer) will be denoted by L2 and 
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L3, respectively* Also, the multicast protocols in the 
second and third layers will be denoted by L2 and L3 
multicast protocols, respectively. 

The information network system in the present 
5 embodiment is constructed by a plurality of logical or 
physical networks, for example, local area networks 
(LAN's) 10 (four LAN's lOA, lOB, IOC and lOD in the 
example shown in Fig. 1), a plurality of inter-LAN relay 
devices 20 (three inter-LAN relay devices 2 OA, 2 OB and 

10 20C in the example shown in Fig. 1) each connected 

between the LAN's for performing the operation of relay 
of information between the LAN's, teirminals 30 (four 
terminals 30A, 30B, 30C and 30D in the example shown in 
Fig. 1) such as personal computers or hosts connected to 

15 the respective LAN's 10, at least one multicast server 40 
connected to any one of the LAN's lOA to lOD for perform- 
ing multicast packet data communication, and so forth. 

In the present embodiment, each inter-LAN relay 
device 20 includes, for example, a communication (or 

20 transmit/receive) processing unit 21, a conversion 

processing unit 22, an L2 multicast protocol processing 
unit 23, a multicast receive processing unit 24, a 
forwarding processing unit 25, and an L2 multicast 
information memory, for example, an L2 multicast table 

25 26. 

The communication processing unit 21 controls 
the communication of information with the corresponding 
LAN (lOA, lOB, etc.) and the external device such as the 
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personal computer 30 or the server 40 through a plurality 
of ports (20a, 20b, etc.) of the inter-LAN relay device 
20. 

The conversion processing unit 22 performs a 
5 processing for conversion for a received multicast 

message from an L3 multicast protocol into an L2 multi- 
cast protocol through a processing shown by, for example, 
a flow chart exemplified in Fig. 4 which will be 
described later on. 
10 The L2 multicast protocol processing unit 23 

performs a processing for an L2 multicast protocol such 
as GMRP, as will be described later on in reference to 
Fig. 11. 

The multicast receive processing unit 24 
15 performs an operation for distribution to a forwarding 
processing, an L2 multicast protocol processing, a 
conversion processing and so forth in accordance with the 
type of a multicast packet through a processing shown by, 
for example, a flow chart exemplified in Fig. 2 which 
20 will be described later on. 

The forwarding processing unit 25 performs an 
operation of transmitting received relay data to a 
predetermined receiver (or destination for transmission) 
as it is . 

25 The L2 multicast table 26 has a column 26a 

indicative of an L2 multicast address and a column 2 6b 
indicative of a receiver port (or the port of destination 
for transmission) which corresponds to the L2 multicast 
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address of the column 26a and to which a terminal 30 
making a declaration of utilization of a multicast 
service is connected^ as exemplified in Fig. 5. 

Each inter-LAN relay device 20 may be construc- 
5 ted by either hardware or software. In the case where 

the inter-LAN relay device 20 is constructed by hardware, 
the processing units 21 to 25 and the table (or memory) 
26 may formed by, for example, discrete ASIC's 
(Application Specific Integrated Circuits) or a single 

10 ASIC. In the case where the inter-LAN relay device 20 is 
constructed by software, the device 20 may be formed by a 
CPU, a ROM, a RAM and an I/O (input/output) circuit, as 
shown in Fig. IB, so that the processing units 22 to 25 
are formed by software in the ROM (for example, a program 

15 module), the processing unit 21 is formed by software in 
the ROM (for example, a program module) and the I/O 
circuit and the table 26 is formed by a part of the ROM 
or RAM. 

An example of the operation of each inter-LAM 
20 relay device 20 in the present embodiment will now be 

described. Though the following description will be made 
in conjunction with an example of the operation of the 
inter-LAM relay device 20A, the similar operation holds 
for the other inter-LAM relay devices 20. 
25 First, the operation of the multicast receive 

processing unit 24 will be described referring to a flow 
chart shown in Fig. 2. 

The monitoring is first made of whether or not 
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a multicast message is received (step 1001). More 
particularly, an MAC header of a message received from 
the server 40 or the personal computer 30 through the LAN 
10 and the port is exsunined to check whether or not the 
5 received message is an L2 or L3 multicast message. 
Namely, if a multicast address (such as an address 
01-00-5E as shown in Fig. 5) is included in the MAC 
header, the judgement of the multicast message as being 
received is made, 
10 In the case where the judgement of the 

multicast message as being not received is made, the 
processing is completed and a wait is taken for the next 
message to be received. 



15 cast message as being received is made, the judgement is 
made of whether or not an L3 multicast protocol message 
as a protocol control message is received (step 1002). 
More particularly, the MAC header and an IP header of the 
received message are examined to check whether or not the 

20 received message has an L3 multicast protocol message. 
Namely, in the case where the received message includes 
an L3 multicast protocol (for example, IGMP), an MAC 
header 100a and an IP header 100b of an IGMP message 
format 100 shown in Fig. 6 are examined to check whether 

25 or not the received message is an L3 multicast protocol 
message . 



multicast protocol message as being received is made, a 



In the case where the judgement of the multi- 



In the case where the judgement of the L3 
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processing for converting the L3 multicast protocol 
message into an L2 multicast protocol message is 
performed (step 1006), as will be described later on in 
reference to Fig. 4, 
5 In the case where the judgement of the L3 

multicast protocol message as being not received is made 
in step 1002, the judgement is made of whether or not an 
L2 multicast protocol message as a protocol control 
message is received (step 1003). More particularly, the 

10 MAC header of the received message is examined to check 
whether or not the received message has an L2 multicast 
protocol message. Namely, in the case where the received 
message includes an L2 multicast protocol (for example, 
GMRP), an MAC header 120a of a GMRP message format 120 

15 shown in Fig. 8 is examined to check whether or not the 
received message is an L2 multicast protocol message. 

In the case where the judgement of the L2 
multicast protocol message as being received is made, a 
processing for L2 multicast protocol is performed (step 

20 1005), as will be described later on in reference to Fig. 
11. 

In the case where the judgement of the Ij2 
multicast protocol message as being not received is made 
in step 1003, the received multicast message is judged as 
25 being not the protocol control message but a usual multi- 
cast data packet and hence a processing for foirwarding to 
a receiver (or destination for transmission) of that 
multicast data packet is performed (step 1004)^ as will 
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be described later on in reference to Fig. 3. 

The forwarding processing performed by the 
forwarding processing unit 25 will now be described. An 
example of the forwarding processing will be described 
5 using a flow chart shown in Fig. 3. First, an L2 multi- 
cast address is read from an MAC header of the received 
L2 multicast message (or usual L2 multicast data packet) 
having a format similar to that of the MAC header 120a of 
Fig. 8 to search an L2 multicast table 26 of Fig. 5 or 

10 the like (step 1101) to check whether or not the read L2 
multicast address exists in the L2 multicast address 
columns 26a of the table 26 or the like, that is, whether 
or not the table search results in a hit (step 1102). In 
the case where the read L2 multicast address exists in 

15 the table 26 or the like, that is, in the case where 

there results in table hit, receiver ports corresponding 
to the read L2 multicast address are read from the 
receiver port column 26a so that the received multicast 
data packet is relayed (or transmitted) through the 

20 transmit/receive processing unit 21 to the read receiver 
ports (or transmit destination ports) excepting the 
receiving port (step 1103). Numerals 1, 3, 5 and so 
forth in the receiver port column 26b shown in Fig. 5 
correspond to the receiver ports 20a, 20b and so forth 

25 shown in Fig. 1. 

On the other hand, in the case where the read 
L2 multicast address does not exist in the table 26 or 
the like, that is, in the case where there results in 



- 19 - 

table mishit, the received multicast data packet is 
relayed (or transmitted) to all the ports of the 
inter-LAN relay device 20 through the transmit/receive 
processing unit 21 or the multicast data packet is 
5 revoked (step 1104). 

Next, an example of the conversion processing 
performed by the conversion processing unit 22 will be 
described using a flow chart shown in Fig. 4. First or 
step 1301, an L3 multicast address in the received 
% 10 multicast message (for example, an IP multicast address 

f; lOOe in an IGMP message format 100 shown in Fig. 6 or an 

hi 

!: IPv4 multicast address lOOe in an IPv4 message format 

shown in Fig. lOA) is converted into an L2 multicast 

s? i 

address (for example, an L2 multicast address 120d in an 

□ 15 GMRP message format 120 shown in Fig. 8 or an L2 multi- 

□ cast address 120d in the GMRP message format 120 shown in 
n Fig. lOB) • For example, 9 upper bits (4 fixed bits and 5 

indeterminate bits) of the IPv4 multicast address lOOe 
shown in Fig. lOA is converted into 2 5 upper bits (a 
20 total of 25 bits including 24 fixed bits of data 

"01-00-5E" indicative of the multicast message plus 1 bit 
of "0") of the L2 multicast address 120d shown in Fig. 
lOB. 

Next, whether or not the received message is a 
25 multicast transmit request is judged from a type value of 
a message format, for example, a type lOOd of an IGMP 
message format 100 shown in Fig. 6 (step 1302). As shown 
in Fig. 7, in the case where the type value of the IGMP 
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message 100c is 0x12, 0x16 or 0x22, the type of the 
message is "VersionX Membership Report" or a transmit 
request and the updating of the L2 multicast table 26 
(see Fig. 5) for entry addition is indicated. On the 
5 other hand, in the case where the type value of the IGMP 
message 100c is 0x17, the type of the message is 
"VersionX Leave Group" or a transmit refusal request (or 
is not a transmit request) and the updating of the L2 
multicast table 26 (see Fig. 5) for entry deletion is 

10 indicated. Also, as shown in Fig. 9, the type of the 
GMPR message corresponding to the type "VersionX 
Membership Report" of the GMPR message 100c is 
"JoinEmpty" or "Joinin" and the type of the GMPR message 
corresponding to the type "VersionX Leave Group" of the 

15 GMPR message 100c is "LeaveAll" or "Leavein". 

Accordingly, in the case where the received 
message is the multicast transmit request (for example, 
in the case where the type value of the IGMP message 100c 
is any one of 0x12, 0x16 and 0x22), the type value of the 

20 IGMP message 100c is rewritten into "JoinEmpty" or 

"Joinin". Thus, the transmit request message 100 of L3 
multicast protocol (for example, the type lOOd and the IP 
multicast address lOOe of the IGMP message 100c) is 
rewritten to generate a transmit request message of L2 

25 multicast protocol and to transmit the generated message 
(step 1304 ) . 

Further, the updating of the L2 multicast 
table 26 (Fig. 5) for entry addition of the thus 
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generated transmit request message of L2 multicast 
protocol is perfoanned (step 1305) • Namely, the L2 
multicast address 120d (Figs, 8 and lOB) of the generated 
L2 multicast protocol message is added into the Ii2 
5 multicast table 26- At this time, the L2 multicast 

address is written into an entry for the same receiver 
port {26b) as a receiver port indicated by the L2 
multicast address . 

On the other hand, in the case where the 

10 received message is not the multicast transmit request, 
the judgement is made of whether or not the received 
message is a multicast transmit refusal request (step 
1303). For example, in the case where the type value of 
the IGMP message 100c is 0x17, the message type is 

15 "VersionX Leave Group" or the received message is not a 
multicast transmit request but a multicast transmit 
refusal request. In the case of the multicast transmit 
refusal request, the type value of the IGMP message 100c 
is rewritten into "LeaveAll", "LeaveEmpty" or "Leavein". 

20 Thus, the transmit refusal request message 100 of L3 

multicast protocol (for example, the type lOOd and the IP 
multicast address lOOe of the IGMP message 100c) is 
rewritten to generate a transmit refusal request message 
of L2 multicast protocol and to transmit the generated 

25 message (step 1306). 

Further, the updating of the L2 multicast 
table 26 (Fig. 5) for entry deletion of the thus 
generated transmit refusal request message of L2 
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multicast protocol is performed (step 1307). Namely, an 
entry of the L2 multicast table 26 corresponding to the 
L2 multicast address 120d (Figs. 8 and lOB) of the 
generated L2 multicast protocol message is deleted. 
5 In the following, specific examples of 

conversion between Ii2 and L3 multicast protocols will be 
described. 

(1) Conversion From L3 Multicast (Join/Leave 
Protocol) Message Into L2 Multicast Message 

10 In the case where the L3 multicast protocol is 

IGMP and the L2 multicast protocol is GMRP, the flow of 
information takes the course of terminal (transmission of 
IGMP message) -> inter-LAN relay device A (conversion into 
GMRP message and transmission thereof) inter-LAN relay 

15 device B, as shown by arrow 210 in Fig. 21. 

As exemplified in Fig. 6, an IGMP message 
format 100 is composed of an MAC header 100a, an IP 
header 100b and an IGMP message 100c including type lOOd, . 
IP multicast address lOOe and other lOOf . The type (or \/ 

20 meaning) of a message indicated by a value set in the 

type lOOd has a relationship as shown by a table 110 in 
Fig. 7. 

On the other hand, a GMRP message format 120 is 
composed of an MAC header 120a and a GMRP message 120b 
25 including type 120c, L2 multicast address 120d and other 
120e, as shown in Fig. 8. The type (or meaning) of a 
message indicated by the type 120c has a relationship as 
shown by a table 130 in Fig. 9. 



- 23 - 

Accordingly, the following is made in the 
conversion from the IGMP message into the GMRP message. 

.^^^^^^In the case of a join message Ay^or example, "Membership 
Report" (0x12/0x16) of the type lOOd of IGMP is replaced 

^^^^by "Joinin" (0x2) of the type 120c of GMRP, In the case 
of a leave message, "Leave Group" (0x17) of the type lOOd 
of IGMP is replaced by "Leavein" (0x4) of the type 120c 
of GMRP. 

Further, the following address conversion is 
10 made, as shown in Figs. lOA and lOB. Namely, in the case 
of IPv4, 23 lower bits of the IPv4 multicast address of 
32 bits in total (Fig. lOA) are remained as they are 
while 9 upper bits thereof are replaced by 25 upper bits 
(including 24 bits on the leading side plus 1 bit of "0") 
15 of the L2 multicast address of 48 bits in total (Fig. 
lOB) . 

Fig. 11 shows a specific exeimple of the flow of 
the L2 multicast protocol processing in step 1005 of Fig. 
2 in the case where the L2 multicast protocol is GMRP. 

20 Namely, in the case where the received L2 

multicast protocol message is "Joinin" or "JoinEmpty" of 
GMRP (step 1201), the updating of the L2 multicast table 
26 for entry addition is performed (step 1203). 

Also, in the case where the received L2 

25 multicast protocol message is "Leavein", "LeaveEmpty" or 
"LeaveAll" of GMRP (step 1202), the updating of the L2 
multicast table 26 for entry deletion is performed (step 
1204) . 
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Fig. 12 shows a specific example of the flow of 
the conversion processing in step 1006 of Fig. 2 in the 
case where the L2 multicast protocol is GMRP. 

Namely, the conversion in the received message 
from the IP multicast address into the L2 multicast 
address is made in a method exemplified in Figs. lOA and 
lOB (step 1401). In the case of a "Membership Report" 
message of IGMP (step 1402), a "Joinin" message of GMRP 
is generated and transmitted (step 1404). Further, the 
updating of the L2 multicast table 26 for entry addition 
is perfoirmed (step 14 05) . 

In the case of a "Leave Group" message of IGMP 
(step 140^3), a "Leaveln" message of GMRP is generated and 
transmitted (step 1405). Further, the updating of the L2 
multicast table 26 for entry deletion is performed (step 
1407) . 

In the case where the L3 multicast protocol is 
MLD and the L2 multicast protocol is GMRP, the flow of 
infoirmation takes the course of terminal (transmission of 
MLD message) -> inter-LAN relay device A (conversion into 
GMRP message and transmission thereof) -> inter-LAN relay 
device B. 

As exemplified in Fig. 26, this MLD message 
format 200 is composed of an MAC header 200a, an IPv6 
header 200b and an IGMP message 200c including type 200d, 
IPv6 multicast address 200e and other 200f. 

A value of 131 set in the type 200d represents 
a "Multicast Listener Report" message indicating a 
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request for joining to a multicast service. A set value 
of 132 represents a "Multicast Listener Done" message 
indicating a request for leaving from the multicast 
service. 

5 Accordingly, in the case where the conversion 

from the LS multicast protocol into the L2 multicast 
protocol corresponding to Fig. 12 is made, the address 
conversion as exemplified in Figs. 16A and 16B is 
performed by copying a portion of 32 lower bits of the 

10 IPv6 multicast address (Fig. 16A) into 32 lower bits of 
the Ii2 multicast address (Fig. 16B) . Further, the 
"Multicast Listener Report" message is converted into 
"Joinin" or "JoinEmpty" of GMRP of L2 . The "Multicast 
Listener Done" message is converted into "Leavein", 

15 "LeaveEmpty" or "LeaveAll" of GMRP. 

The correspondence relationship in conversion 
between the L2 multicast protocol and the L3 multicast 
(join/leave protocol) message as mentioned above is shown 
on the upper stage side of a table 150 of Fig. 20 in 

20 conjunction with the case where L2 is GMRP and L3 is IGMP 
and MLD. 

(2) Conversion From L3 Multicast (Routing 
Control Protocol) Message Into L2 Multicast Message 

In the case where the L2 multicast protocol is 
25 GMRP and the L3 multicast protocol is DVMRP, the flow of 
information takes the course of inter-LAN relay device A 
(transmission of DVMRP message) -» inter-LAN relay device 
B (conversion into GMRP message and transmission thereof) 



• 
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-> inter-LiAN relay device C, as shown by arrow 220 in Fig. 
21. 

For DVMRP in this case, a DVMRP message format 
160 is composed of an MAC header 160a, an IP header 160b 
5 and a DVMRP message 160c including code 160d, IP 

multicast address 160e and other 160f, as shown in Fig. 
22. The meaning of a value set in the code 160d is such 
that code = 7 indicates a Prune message and code = 8 
indicates a Graft message. 
10 "Graft" and "Prune" of DVMRP are respectively 

converted into "Join" system and "Leave" system messages 
of GMRP, as shown on the lower stage side of the table 
150 in Fig. 20. 



15 GMRP and the L3 multicast protocol is PIM-DM, the flow of 
information takes the course of inter-LAN relay device A 
(transmission of PIM-DM message) ^ inter-LAN relay device 
B (conversion into GMRP message and transmission thereof) 
inter-LAN relay device C . 

20 For PIM-SM/DM in this case, a PIM-SM/DM message 

format 170 is composed of an MAC header 170a, an IP 
header 17 0b and a PIM-SM/DM message 170c including type 
170d, IP multicast address 170e and other 170f, as shown 
in Fig. 23. The meaning of a value set in the type 170d 

25 is such that type = 3 indicates a Join/Prune message and 
type = 6 indicates a Graft message. 



In the case where the L2 multicast protocol is 
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Graft" and "Join"/ "Prune" of PIM-DM are 



respectively converted into "Join" s 



ystem and "Leave 



tt 



- 27 - 

system messages of GMRP, as shovm on the lower stage side 
of the table 150 in Fig. 20. 

In the case where the L2 multicast protocol is 
GMRP and the L3 multicast protocol is PIM-SM, the flow of 
5 information takes the course of inter-LAN relay device A 
(transmission of PIM-SM message) -> inter-LAN relay device 
B (conversion into GMRP message and transmission thereof) 
-> inter-LAN relay device C . 

A message format in this case has already been 

10 described in conjunction with Fig. 23. "Join"/ "Prune" of 
PIM-SM is converted into "Join" system and "Leave" system 
messages of GMRP^ as shown on the lower stage side of the 
table 150 in Fig. 20. 

In the case where the L2 multicast protocol is 

15 GMRP and the L3 multicast protocol is CBT , the flow of 

information takes the course of inter-LAN relay device A 
(transmission of CBT message) -» inter-LAN relay device B 
(conversion into GMRP message and transmission thereof) 
inter-LAN relay device C. 

20 For CBT in this case, a CBT message fojrmat 180 

is composed of an MAC header 180a, an IP header 180b and 
a CBT message 180c including type 180d, IP multicast 
address 180e and other 180f, as shown in Fig. 24. The 
meaning of a value set in the type 180d is such that type 

25 =1 indicates a JOIN_REQUEST message and type = 3 
indicates a QUIT_NOTIFICATION message. 

" JOIN^REQUEST" and "QUIT_NOTIFICATION" of CBT 
are respectively converted into "Join" system and "Leave" 




- 28 - 

system messages of GMRP, as shown on the lower stage side 
of the table 150 in Fig. 20. 

In the case where the L2 multicast protocol is 
GMRP and the L3 multicast protocol is MOSPF, the flow of 
5 information takes the course of inter-LAN relay device A 
(transmission of MOSPF message) inter-LAN relay device 
B (conversion into GMRP message and transmission thereof) 
-> inter-LAN relay device C. 

For MOSPF in this case, an MOSPF message foirmat 

10 190 is composed of an MAC header 190a, an IP header 190b 
and an MOSPF message 190c including type 190d, IP 
multicast address 190e and other 190f, as shown in Fig. 
25* The meaning of a value set in the type 190d is such 
that type = 6 indicates a Group-membership-LSA message. 

15 "Group-membership-LSA" of MOSPFT is converted 

into a "Join" system message of GMRP, as shown on the 
lower stage side of the table 150 in Fig. 20. 

(3) Conversion From L2 Multicast Message into 
L3 Multicast (Join/Leave Protocol) Message 

20 A general receive processing flow in the case 

of a processing for conversion from the L2 multicast 
protocol into the L3 multicast protocol is shown in Fig. 
13 (which corresponds to Fig. 2). This processing is 
performed by a receive processing unit 24 shown in Fig. 

25 17 which will be described later on. 

First, the presence/absence of reception of an 
L2 multicast message is monitored (step 1501). In the 
case where the L2 multicast message is received, the 
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judgement is made of whether or not the received message 
is an L2 multicast protocol message (step 1502 )• In the 
case where the received message is an L2 multicast 
protocol message, an L2 multicast protocol processing as 
5 exemplified by the flow chart of Fig. 11 having already 
been mentioned is performed (step 1504) and a processing 
for conversion into an L3 multicast protocol is performed 
(step 1505) . 

In the case where the judgement of the received 

10 message as being not an L2 multicast protocol message is 
made in step 1502, there is performed a forwarding 
processing similar to that in step 1004 of Fig. 2 in 
which the message is forwarded to the destination for 
relay as it is (step 1503). 

15 In the conversion processing in step 1505, 

there is performed a processing exemplified by a flow 
chart in Fig. 14. 

First, the multicast address conversion from L2 
to L3 is made in a method exemplified in Figs. lOA and 

20 lOB or Figs. 16A and 16B (step 1601). Next, in the case 
where a received L2 message is a multicast transmit 
request (step 1602), a transmit request message of L3 
multicast protocol having an equivalent meaning is 
generated and transmitted to the destination for relay 

25 (step 1604). In the case where the received L2 message 
is not a multicast transmit request, the exeunination is 
made of whether or not the message is a multicast 
transmit refusal request (step 1603). In the case where 
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the message is a multicast transmit refusal request, a 
transmit refusal message of L3 multicast protocol having 
an equivalent meaning is generated and transmitted to the 
destination for relay (step 1605). 
5 A more specific example of the conversion 

processing will be described by use of a flow chart in 
Fig. 15 in conjunction with the case where the L2 
multicast protocol is GMRP and the L3 multicast protocol 
is IGMP. 

10 The flow of information in this case takes the 

course of terminal (transmission of GMRP message) -> 
inter-LAN relay device A (conversion into IGMP message 
and transmission thereof) -» inter-LAN relay device B, as 
shown by arrow 2 30 in Fig. 21. 

15 First, the multicast address conversion from L2 

to L3 is made in a manner similar to that in Figs. lOA 
and lOB (step 1701). Next, in the case where a received 
L2 multicast protocol message is "Joinin" or "JoinEmpty" 
of GMRP (step 1702), a "Membership Report" message of 

20 IGMP for L3 equivalent thereto is generated and trans- 
mitted to the destination for relay (step 1704). 

In the case where the received L2 multicast 
protocol message is "Leavein" or "LeaveEmpty" of GMRP 
(step 1703), a "Leave Group" message of IGMP for L3 

25 equivalent thereto is generated and transmitted to the 
destination for relay (step 1705). 

Also, in the case where the L2 multicast 
protocol is GMRP and the L3 multicast protocol is MLD. 
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The flow of information in this case takes the course of 
terminal (transmission of GMRP message) -> inter-LAN relay 
device A (conversion into MLD message and transmission 
thereof) -> inter-LAN relay device B. In this case, in 
5 the above-mentioned conversion processing in step 1704, 
"Multicast Listener Report" of MLD is generated and 
transmitted. Also, in the processing in step 1705, 
"Multicast Listener Done" is generated and transmitted. 

(4) Conversion From L2 Multicast Message Into 

10 L3 Multicast (Routing Control Protocol) Message 

In the case where the L2 multicast protocol is 
GMRP and the L3 multicast protocol is DVMRP, the flow of 
information takes the course of terminal (transmission of 
GMRP message) -> inter-LAN relay device A (conversion into 

15 DVMRP message and transmission thereof) inter-LAN relay 
device B, as shown by arrow 240 in Fig. 21. "Join" 
system and "Leave" system messages of GMRP are converted 
into "Graft" and "Prune" of DVMRP, respectively. 

Similarly, in the case where the L2 multicast 

20 protocol is GMRP and the L3 multicast protocol is PIM-SM, 
the flow of infoirmation takes the course of terminal 
(transmission of GMRP message) inter-LAN relay device A 
(conversion into PIM-SM message and transmission thereof) 
inter-LAN relay device B. "Join" system and "Leave" 

25 system messages of GMRP are converted into "Join"/ "Prune" 
of PIN-SM. 

Similarly, in the case where the L2 multicast 
protocol is GMRP and the L3 multicast protocol is PIM-DM, 
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the flow of information takes the course of terminal 
(transmission of GMRP message) inter-LAN relay device A 
(conversion into PIM-DM message and transmission thereof) 
inter-LAN relay device "Join" system and "Leave" 

5 system messages of GMRP are converted into "Graft" and 
"Join"/ "Prune" of PIM-DM, respectively. 

Similarly, in the case where the L2 multicast 
protocol is GMRP and the L3 multicast protocol is CBT, 
the flow of information takes the course of terminal 

10 (transmission of GMRP message) -> inter-LAN relay device A 
(conversion into CBT message and transmission thereof) 
inter-LAN relay device B. "Join" system and "Leave" 
system messages of GMRP are converted into "JOIN REQUEST" 
and "QUIT NOTIFICATION" of CBT, respectively. 

15 Similarly, in the case where the L2 multicast 

protocol is GMRP and the L3 multicast protocol is MOSPF, 
the flow of information takes the course of terminal 
(transmission of GMRP message) ^ inter-LAN relay device A 
(conversion into MOSPF message and transmission thereof) 

20 -> inter-LAN relay device B. A "Join" system message of 
GMRP is converted into "Group-membership-LSA" of MOSPF. 

Next, the reference to Figs. 17, 18, 19 and so 
forth will be made to show an example in which multicast 
packets flowing on the information network system are 

25 monitored to collect and register prefix portions of 

multicast addresses so that the registered prefix address 
portion is utilized in a processing for conversion from 
an L2 multicast protocol into an L3 multicast protocol. 
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As exemplified in Fig. 17, each of the 

inter-LAN relay devices 20 (20A, 20B, 20C, ) shown in 

Fig. 1 is additionally provided with a monitor processing 
unit 27 for monitoring an L3 multicast packet to be 
5 relayed, thereby extracting a prefix portion of its 

multicast address (for example, 9 leading bits of IPv4 in 
Fig. lOA or 96 leading bits of IPv6 in Fig. 16A) , and a 
multicast address memory such as a conversion table 140 
(28) for storing the extracted prefix address. The 

10 monitor processing unit 27 may be formed by an ASIC or 

program, and the table 140 may be fommed by an ASIC or a 
part of ROM or RAM. 

As exemplified by a flow chart shown in Fig. 
19, the monitor processing unit 27 monitors whether or 

15 not an IP multicast packet of L3 is received (step 1801). 
When it is received, the monitor processing unit 27 reads 
a prefix address portion of an IP multicast address and 
stores it into the conversion table 140 (see Fig. 18) for 
each type (step 1802). 

20 In generating an IP multicast address lOOe at 

the time of conversion from a GMRP message of Ii2 into an 
IGMP message of L3 (as shown in Fig. 6), for example, as 
in step 1601 of the flow chart of Fig. 14 (corresponding 
to that of Fig. 4) or step 1701 of the flow chart of Fig. 

25 15 (corresponding to that of Fig. 12), the corresponding 
data registered in the conversion table 140 is used for 
generating 9 upper bits other than 23 lower bits (in the 
case of Fig. lOA) of the IP multicast address taken over 
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from the GMRP message or 96 upper bits other than 32 
lower bits (in the case of Fig. 16A) thereof. 

Next^ the reference to Figs. 27 and 28 will be 
made to describe an actual operation in which after a 
5 processing for a request for joining to multicast service 
transmitted from a specified terminal 30 is performed in 
the above-mentioned processing for conversion between L2 
and L3 multicast protocols, a multicast packet trans- 
mitted from a multicast server 40 is selectively relayed 

10 to the terminal 30. 

An L3 multicast memory such as an L3 multicast 
table 250 exemplified in Fig. 27 is stored with an IP 
multicast address 250a as a destination address and a 
corresponding receiver IP subnet 250b having the list of 

15 one or plural subnet masks for specifying one or plural 
subnets to which a multicast packet with that multicast 
address is to be relayed. 

Though not shown in Fig. 1 or 17, the L3 
multicast table 250 is mounted on the inter-LAN relay 

20 device 20 (20C) which functions as a router for 

performing an L3 relaying operation for the widely used 
L3 multicast protocol such as IGMP. The table 250 may be 
formed by an ASIC, ROM or RAM. 

First, when an IP multicast packet is received 

25 (step 1901), the L3 multicast table 250 is searched using 
the received multicast address (step 1902). In the case 
where there results in a hit, 23 lower bits of a value 
registered in the L2 multicast address colximn 26a of the 
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L2 multicast table 26 (see Fig. 5) are searched by use of 
23 lower bits of the IP multicast address (step 1903). 
In the case where there results in a hit, the IP multi- 
cast packet is selectively relayed to a terminal 30 
5 connected to a receiver port stored in the receiver port 
column 26b of the table 26 (step 1904). 

In the case where the search in step 1902 or 
1903 results in a mishit, the IP multicast packet is 
revoked (step 1905). 

10 In connection to the above-mentioned conversion 

between the multicast protocols of L2 and L3 levels in 
the present invention. Figs. 29A and 29B and Figs. 30A 
and 30B show a processing for conversion and transmission 
of a multicast service join message (or pre-procedure ) 

15 and the behavior of traffic reduction in an actual multi- 
cast packet transmission control processing performed 
after this pre-procedure. 

Figs. 29A and 29B correspond to the case where 
each of all inter-LAN relay devices 20 (switches) is 

20 provided with a function of multicast protocol conversion 
between L2 and L3 in the present invention. 

The pre-procedure in this case is performed as 
shown in Fig. 29A, Namely, in an inter-LAN relay device 
20 (20A) connected to a terminal 30 and functioning as an 

25 L2 level switch, IGMP of L3 level transmitted from the 

terminal 30 is converted into GMRP of L2 level. The GMRP 
of L2 level is transmitted from the inter-LAN relay 
device 20 (20A) to the other inter-LAN relay devices 20 
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(20B, 20C, ). The original IGMP of L3 level is also 

transmitted to the other inter-LAN relay devices 20 (20B, 

20C, ) after passed through the inter-LAN relay device 

20 (20A) as it is. 
5 After the execution of the above pre-procedure , 

an IP multicast packet arriving the inter-LAN relay 
device 20 (20C) on the backbone side from a multicast 
server 40 is selectively transmitted to only the terminal 
30 in the IP subnet, as shown in Fig. 29B, as if the 
% 10 terminal 30 supported the multicast protocol of L2 level 

f: even in the case where the terminal 30 is not provided 

r! with a function of processing GMRP of L2 level. 

Figs. 30A and 30B correspond to the case where 
only an inter-LAN relay device 20 (20C) on the backbone 

□ 15 side is provided with a function of multicast protocol 

□ conversion between L2 and L3 in the present invention. 

z I 

n In this case, as shown in Fig. 30A, IGMP of L3 

level transmitted from a terminal 30 is passed through an 
inter-LAN relay device 20 (20A) connected to the terminal 

20 30 and functioning as an L2 level switch and is there- 
after transmitted to the inter-LAN relay device 20 (20C) 
on the backbone side. In the inter-LAN relay device 20 
(20C), the IGMP of L3 level transmitted from the terminal 
30 is converted into GMRP of L2 level. The GMRP of L2 

2 5 level is transmitted to all the inter-LAN relay devices 

20 (20A, 20B, 20C, ). 

After the execution of the above pre-procedure, 
an IP multicast packet arriving the inter-LAN relay 
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device 20 (20C) on the backbone side from a multicast 
server 4 0 is selectively transmitted to only the terminal 
30 in the IP subnet, as shown in Fig. 30B, as if the 
terminal 30 supported the multicast protocol of L2 level 
5 even in the case where the terminal 30 is not provided 
with a function of processing GMRP of L2 level. 

Thus, according to the information relay device 
in the present embodiment, with a construction in which a 
multicast protocol of L3 level such as IGM which has come 

10 into wide use in association with a general purpose OS 
for a personal computer or the like is converted into a 
multicast protocol of L2 level such as GMRP which has not 
yet come into so wide use but is capable of a service for 
selective delivery of a multicast protocol, it is 

15 possible to realize a multicast service with a reduced 
traffic resulting from the selective delivery of a 
multicast packet in a subnet by the multicast protocol of 
L2 level. Namely, it becomes possible to realize a 
multicast service without increasing the traffic in a 

20 subnet beyond the requisite amount thereof. 

Also, with a construction in which a multicast 
protocol of L2 level such as GMRP or the like the degree 
of utilization of which is low as yet is mounted on only 
inter-LAN relay devices 20 such as bridges or routers the 

25 number of which is relatively small, even if such a 

multicast protocol of L2 is not mounted on a large number 
of terminals 30 such as hosts connected to information 
networks, it is possible to realize the selective 
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delivery of a multicast packet in a subnet by the 
multicast protocol of L2 level. Namely, it is possible 
to realize the simplification of mounting of multicast 
software in a host connected to a network and utilizing a 
5 multicast service. 

In other words, there are compatibly enabled 
the suppression of an increase in traffic in a network 
which is caused from a multicast service and the 
easy/convenient realization and utilization of the 

10 multicast service which results from the simplification 

of mounting of multicast software on a terminal such as a 
host connected to the network. 

Further, with a construction in which software 
for performing the conversion between multicast protocols 

15 of L2 and L3 levels is merely mounted on inter-LAN relay 
devices 20 the number of which is small as compared with 
that of teirminals, the utilization of a variety of multi- 
cast protocols in a network becomes possible. Namely, 
there are compatibly enabled the simplification of 

20 mounting of multicast software in a host connected to a 
network and the utilization of a variety of multicast 
protocols . 

In the foregoing, the present invention has 
been disclosed on the basis of the embodiments thereof. 
25 However, it is needless to say that the present invention 
is not limited to the disclosed embodiments and various 
changes or modifications are possible in a rage which 
does not depart from the gist of the present invention. 
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For example, the multicast protocols of L2 and 



L3 levels made the object of conversion processing in the 
present invention are not limited to those exemplified in 
the foregoing embodiments. There can also be applied to 
5 other protocols so long as the conversion is made so that 
essential information in a protocol message concerning a 
multicast service is logically reserved in conversion 
between L2 and L3 levels. 



10 20 in the foregoing embodiments is formed by software, as 
shown in Fig. IB, processing programs and data shown in 
Figs. 2 to 12 and so forth may be installed later on 
instead of being installed in the ROM (and RAM) of the 
inter-LAN relay device beforehand. Namely, such 

15 processing programs and data may be recorded in a 

recording medixim such as a CD-ROM. The programs and data 
recorded in the recording medium can be written into the 
ROM (and RAM) of the inter-LAN relay device 20 by setting 
the recording medium on a recording medium reading unit 

2 0 151 connected to the inter-LAN relay device 2 0 and 

connecting the recording medium reading unit 151 to the 
I/O circuit of the inter-LAN relay device 20. Alter- 
natively, such processing programs and data may be loaded 
down onto the ROM (and RAM) of the inter-LAN relay device 

25 20 through the network so that they are written 
thereinto. 



In the case where each inter-LAN relay device 



